NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/435

Internet Message Format | 1996-08-06 | 4.1 KB

From: [e-mail] (J. Kanze)
Message-ID: <[e-mail]>
X-Original-Date: 22 Feb 1996 13:42:32 GMT
Path: in2.uu.net!bounce-back
Date: 22 Feb 96 14:11:31 GMT
Approved: [e-mail]
Newsgroups: comp.std.c++
Subject: Re: An STL helper -- and template and type shenanigans
Organization: GABI Software, Sarl.
References: <[e-mail]>
    <[e-mail]>
    <4eto87$[e-mail]> <[e-mail]>
    <4gfg21$[e-mail]>
In-Reply-To: [e-mail]'s message of 21 Feb 1996 09:56:42 PST
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMSx50+EDnX0m9pzZAQElDQF/eI4zYNDf6C2XA9gwkRqQrugOL9NNVktS
    89r8gpIkTGjrtGH8+ZuJ/7OZ6NQK016A
    =fFOG

In article <4gfg21$[e-mail]> [e-mail]
(Pablo Halpern) writes:

|> [e-mail] (J. Kanze) wrote:

|> >In article <4eto87$[e-mail]> [e-mail] (Joe
|> >Buck) writes:
|> >> The *language*, not just STL, requires copy constructors that actually
|> >> copy.  The language automatically uses the copy constructor whenever it
|> >> needs to make a copy.  The copy constructor is used to return objects
|> >> from functions and to pass them in by value.  This usaga assumes that
|> >> you get an actual copy.  Copy constructors can be optimized away in
|> >> certain circumstances.  Again, this optimization works based on the
|> >> assumption that a copy constructor does a copy, so you can avoid the
|> >> copy by constructing the object in the right place.  It also means that
|> >> having a side effect in the copy constructor (other than something that
|> >> preserves copy semantics, like reference counting and such) is going to
|> >> break things.

|> >In all cases where the language (outside of the library) does an
|> >implicite copy, the object being copied is destructed immediately after,
|> >before the user can use it for anything else.  So a `copy' that in fact
|> >`moves' will still work.

|> Hmmm... I take it that you don't consider pass-by-value to be an
|> implicit copy? Perhaps you're right, but I don't really see where the
|> implicit vs. explicit question enters into this. I consider it an axiom
|> that if you assign "a = b" that you can then assume that "a == b" is
|> true unless a or b are volatile. If you write a copy constructor or
|> assignment operator such that this is NOT true, then you are asking for
|> trouble, IMHO. This leaves me with a delema wrt auto_ptr<> because,
|> while I like what it is trying to do, I don't like the idea of breaking
|> fundamental axioms in such a flagrant way. This could cause a ripple
|> effect. I'm not sure what kinds of compiler optimizations might not be
|> possible or even if certain semantics might become unpredicatable in
|> this case. Maybe I'm overstating the problem. Auto_ptr<> semantics seem
|> simple enough on the face of it and maybe this isn't a problem in
|> reality. (Programming, especially in C++, is not expected to be the same
|> as mathmatics, after all.)

You're not overstating anything.  You have precisely described the
dilemma concerning auto_ptr, and why there is so much discussion about
it.

In general, I agree with the concerning voiced about the changed
semantics of operator=.  In the case of auto_ptr, however, in all of the
cases where I think one would reasonably want to use it, the value on
the right hand side is either a temporary, or a value about to disappear
anyway.  So the changed semantics don't bother me too much.
--
James Kanze           ([phone]          email: [e-mail]
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:[e-mail]
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:[e-mail].
]